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ABSTRACT 



Digital logic testing occurs in two different test 
environments, digital simulation and actual hardware testing. 
A computer aided design (CAD) tool applies a set of 
stimulus/response test vector patterns to check the 
functionality of a digital circuit design. Once manufactured, 
the chip with this design is tested by a hardware tester 
system (i.e. automatic test equipment (ATE)). The ATE 
performs many tests in addition to the functionality test. 
However, the stimulus/response test vector formats used in 
these two environments are different and, therefore, 
incompatible in present form. 

This thesis is aimed at two major objectives. First, a 
system study will be performed on the GenRad-125 VLSI Hardware 
Tester System, including its usage, test capabilities and 
limitations. Secondly, this thesis addresses the problem of 
test vector format incompatibility between the two testing 
environments. Special UNIX tools, Lex & Yacc, are used to 
create a software translator which changes the CAD simulation 
file into the GenRad-125 Hardware Test System format. 
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INTRODUCTION 



I . 

A. DESIGN FOR TESTABILITY BACKGROUND 

Electronic circuit testing has become an extremely crucial 
step in SSI/LSI/VLSI digital circuit design and manufacturing. 
In the past, digital component testing was considered at best 
a "post -design" activity [Ref. 1] . Digital testing seemed to 
occur last in the R&D, design, prototype, and production 
sequence. However, manufacturing industries of today are 
discovering that the high costs associated with testing amount 
up to 60% of the total production costs [Ref. 2:p. v] . 
Furthermore, recent increases in digital design complexity 
give rise to a situation where a circuit designer can produce 
a digital circuit which is virtually un-testable completely. 
Therefore, the only way to reduce this cost is to incorporate 
test activities into the design process, hence, creating a 
"testable design" [Ref. 2]. 

In order to pursue a testable design it is necessary to 

define the term "circuit testability". 

A circuit is testable if a set of test patterns can be 
generated, evaluated and applied in such a way as to 
satisfy pre-defined levels of performance, defined in 
terms of fault-detection, fault- location and test- 
application criteria, within a pre-defined cost budget and 
time scale [Ref. 2:p. ix] . 
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B. DESIGN TESTING PROCESS 

Modern digital circuit testing occurs within two design 
environments, simulation tests and actual hardware testing. 
A Computer Aided Design (CAD) tool with an interactive logic 
simulator tests the functionality of a digital circuit design. 
This CAD logic simulator allows a specific design test cycle: 
stimulus application, simulation, results analysis, and design 
modification. This thesis will utilize the Mentor Graphics 
Quicksim CAD tool for an actual design conducted within the 
computer simulation environment. 

Actual hardware testing using Automatic Test Equipments 
(ATE) , such as the GenRad GR125 VLSI Tester, compose the 
second test environment. Once a digital chip is manufactured, 
a series of testing is performed. In addition to logic 
functionality, modern ATEs also perform D.C. Parametric, A.C. 
Parametric, Functional and Power Supply tests. This thesis 
will analyze the capability of the GenRad GR125 VLSI Test 
System and examine the testing cycle within the integrated 
hardware testing environment. 

As described above, a chip design will be tested in both 
environments. Testing for functionality allows the digital 
chip designer to determine if his design responds correctly to 
a given input stimuli (i.e. does the chip logic function work 
as expected) . To test this aspect of the design, a set of 
stimuli and expected response patterns are applied to the 
chip's input and output pins. This set of input stimuli and 
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expected response patterns are known as test vector patterns. 
However, both the Mentor Graphics Quicksim, and the ATE, 
GenRad GR125 VLSI Test System are stand-alone systems. The 
test vector pattern syntaxes used in each environment are not 
compatible. As a result, presently, test vector patterns for 
two separate formats must be generated. 

C. THESIS OBJECTIVES 

This thesis has two major objectives achieved within the 
hardware and software design and test environments. First, a 
thorough study was performed on the GenRad GR125 VLSI hardware 
test system, which reveals its usage, test capabilities and 
limitations. Secondly, this thesis provides a solution to the 
problem of test vector pattern incompatibility between the 
simulation and tester environments. Special UNIX tools, Lex 
and Yacc, are used to create a software translation program to 
bridge this incompatibility gap. This translation program 
provides an interface between the test vector patterns 
generated from the Mentor Graphics Quicksim simulator and the 
required format for the GenRad- 125 VLSI hardware tester 
system. 
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II. HARDWARE TEST ENVIRONMENT 



Automatic Test Equipment (ATE) provides the capability to 
thoroughly test a digital logic chip in a power on situation. 
There are many modern ATE’s similar in functionality. 
However, this thesis will be focused on one specific ATE: the 
GenRad GR125 VLSI Test System (GR-125). In order to reveal 
the complete hardware test system, three major areas will be 
discussed. The first area provides a comprehensive overview 
of the GR-125 focusing on its characteristics, main component 
layout and system software implementation. Secondly, the 
overall programming and execution methodology for component 
testing will be analyzed. This methodology will be described 
in four major phases (Data Input, Translation, Execution and 
Results) . The discussion concerning the software interface to 
the GR-125 will lead to discussion in chapters III and IV of 
this thesis. Finally, the third major area of discussion 
identifies some special testing capabilities of the GR-125. 

A. SYSTEM OVERVIEW (GENRAD- 125) 

The GenRad GR-125 tester provides a broad range of digital 
logic testing capability. However, in order to effectively 
utilize this capability a basic understanding of GR-125 
characteristics, system structure and system software is 
required. Therefore, the purpose of this system overview is 
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to provide a logical, comprehensive and user-friendly 
documentation for the GR-125 tester operation. The approach 
taken here will focus on the user's perspective instead of 
technical manual details. 

1. General 

The GR-125 is classified as a low voltage digital 
logic tester. Although originally designed for high quantity 
output production testing, the GR-125 provides an excellent 
research testing platform for diagnostic analysis of 
individual chips. As the name implies, the GenRad GR125 VLSI 
test system has the flexibility to accommodate a wide range of 
chip component complexity. The entire spectrum of complexity 
from Small Scale Integration (SSI) to Very Large Scale 
Integration (VLSI) are accommodated by the GR-125. The 
complexity of the digital component under test is limited only 
by its maximum number of pins. 

2 . Rating Characteristics 

The GR-125 has the capability to test any digital 
device up to a maximum of 64 pins. As discussed above, these 
pins consist of low voltage only ( | 0 - 8 J volts). Of the total 
pin count, half the pins can function as drive elements and 
half the pins can function as sense elements. Drive pins are 
used to put a desired digital stimulus signal on a pin. Sense 
pins, however, use comparators to compare the actual pin 
condition signal with the expected pin condition values. The 
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timing signals for chip testing are generated by a 12.5 Mhz 
clock. Memory capacity of the GR-125 limits each test pin to 
64 Kbytes of test vectors. Table I provides a summary of 
these general characteristics for the GR-125. 

Table I GR-125 RATING CHARACTERISTICS 

... 64 pins low voltage 
(0-8 volts) 

... 12.5 Mhz clock speed 

... 64 Kbytes of test vector memory 
per pin 

... 32 Drive pins 

... 32 Sense pins 



3. Basic System Structure 

The GR-125 test system consists of two subsystems: 
main assemblies and peripheral Input/Output (I/O) devices. 
Refer to Figure 1 for an overall structure layout. 
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a. Main Assemblies 

There are two main subsystems which make up the GR* 
125 test system: Mainframe and Test Head. The Mainframe 
functions as the central control unit which houses the power 
supply, computer, and test signal generator of the tester. 
The Test Head houses various interface adaptor boards which 
connect to the Device Under Test (DUT) via plug-in connectors. 
Circuits located within the Test Head provide an interface for 
the test signals between the main frame and DUT. Three 
subassemblies are contained in the Mainframe: the System Power 
Supply Bay, CPU Card Cage, and Test Electronics Card Cage. 
Refer to figure 2. 
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I/O 

DEVICES 



OUT 



Figure 2 GR-125 Main Assembly Structure [from Ref. 3] 



b. Peripheral I/O Devices 

Various peripheral I/O devices are also 
incorporated within the GR-125 test system. The VT-220 Video 
Display Terminal presents menu formatted user screens to set 
up detailed test requirements, to observe test results and to 
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interact with the CPU via a UNIX based software. 



In its 



present set up conditions, the Printer works in a screen dump 
mode allowing the Print Screen command only. Although 
restrictive, this set up is adequate for obtaining a hard copy 
test result. The Keypad (refer to figure 1) was designed to 
be used when performing routine testing under high production, 
high volume test conditions. Because of the low volume and 
research orientation of this thesis, the operation of the 
keypad will not be addressed. On the front of the Mainframe 
is a control panel which holds the main power switches. A 
magnetic disk and tape unit is located next to these switches. 
This disk and tape I/O device provides an electronic copy 
capability for program and data storage as well as system 
backups. Because an Ethernet card is not available, the 
present GR-125 hardware tester is a stand alone system. 

4. System Software Description 

The heartbeat of the GR-125's operation is its system 
software. The GR-125 test system utilizes UNIX and custom 
software packages to form the backbone operating system for 
the GR-125 tester. Because of its wide acceptance in 
industrial and engineering applications, UNIX software 
provides an interactive and general purpose operating system. 
The version of UNIX software installed in the GR-125 is the 
UniPlus+ software (v2.0) , which runs on the Motorola 68000 CPU 



9 



chip. This UniPlus+ software resides in a 15 Mbyte space on 
the 85 Mbyte hard disk. 

a. Operating- System 

The UniPlus+ consists of both an operating system 
and its utilities. The custom software works as a link 
between the user and the GR-125 test system controlling 
several I/O functions. Refer to figure 3. This custom 

software permits the extensive use of interactive user menu 
screens. These screens, which will be covered later in 
detail, allow an operator to set up the GR-125 to test a 
device as well as developing new test programs (on-line or 
off-line) . 




b. Utilities 

In addition to its operating system, the UNIX 
software package also contains many help utilities. See 
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Figure 4. These utilities enable a user to develop new test 
programs and make modifications to existing programs. The 
file system consists of both ASCII text and binary data files 
stored on the hard disk. The main purpose of the file system 
is to act as a storage mechanism for test programs and system 
configuration data associated with particular test programs. 



Figure 4 Uni?lus+ Utilities [from Ref. 3] 

The UNIX software package also supports three 
different editors: ACS, vi, and uEMACS . The More command 
allows a text file to be read one screen at a time. As a 
stand alone system, this particular GR-125 setup does not 
support Electronic Mail. The RCS (Revision Control System) 
makes up the last of the major UNIX utilities supported by the 
GR-125 test system. The RCS manages software libraries. It 
stores and retrieves multiple revisions of program and test 
files. Furthermore, the RCS maintains a complete history of 
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changes between test program versions so that one can easily 
find the changes made between different versions. For more 
details on RCS refer to Ref. B. 

B. TEST PROGRAMMING AND EXECUTION METHODOLOGY 

Test programming and execution methodology describes the 
overall GR-125 testing procedure from data input to observable 
test results. This section will present the four main phases 
of the GR-125 procedure: Data Input, Translation, Execution, 
Results. Refer to Figure 5. The first phase of the testing 
procedure includes a software interface to the GR-125 tester 
as illustrated in Figure 6. Test pattern information and 
parameter specification data are input during this phase. 
Next, during the translation process, ASCII formatted data in 
the software interface is translated to binary code for use by 
the GR-125 tester. Once the required binary files are 
obtained, the GR-125 can support a variety of test executions 
By manipulating different support screens within the test 
execution phase, the user can produce several desired output 
formats. The Results phase produces several categories of 
results depending on the option chosen during the Execution 
phase. In the following discussion, the purpose is to 
describe this testing methodology in a manner which provides 
the most benefit to the GR-125 user. 
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Figure 5 GR-125 Testing Procedure Phases 



1. Data Input Phase 

Two software files are used to enter the Device Under 
Test (DUT) specification to the GR-125 tester. The test 
pattern processor (.tpp) file defines the actual pin mapping 
and test vector configuration of the GR-125. Secondly, the 
parameter specification file contains the bulk of the 
programming information necessary to perform a successful 
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test. Data is placed into this file through the use of custom 
Programming Screens. These screens prompt the user for a wide 
range of component parameters from pin current levels to 
timing specifications. 

a. Test Pattern (.tpp) File 

The first step in the development of a GR-125 test 
program is the generation of a .tpp file. This file contains 
the tester pins to device pins mapping information. 
Additionally, the actual test vector patterns which are 
applied to the DUT are also incorporated into this file. It 
is important to note that the .tpp file is an ASCII text file 
created by any generic text editor. Figure 7 illustrates a 
basic .tpp file for a 7404 Hex Invertor. 

The -tpp file is made up of three sections: 
PINDEFS, ADAPTOR, and MODULE. The PINDEFS and MODULE sections 
are mandatory. The ADAPTOR section contains the only optional 
entries. [Ref. 5:p. 1-5] 

(1) PINDEFS Section. The PINDEFS section is 
composed of columns of information to inform the GR-125 tester 
of the physical (adaptor) connections between the GR-125' s 
tester channels and the DUT. This section contains the tester 
pin mapping information. Figure 8 illustrates a typical pin 
assignment for a 74F374 Octal D-Type Flipflop. In this 
example, the 74F374's pin #1 (output enable line "/oe") is 
connected to the GR-125 tester channel #3. Note, however. 
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Figure 6 GR-125 Testing Methodology 
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Figure 7 74S04 Hex Inverter . tpp File 
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that: the 74F374's power and ground pins are not connected to 
GR- 125 tester channels. Ground and power pins (pins #10 and 
#20 on the device socket) are already internally wired to the 
adaptor. [Ref. 5:p. 4-5] 
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Figure 1-1. GRlXX Tester Channel Assignment 



Fig-ure 8 GR-12 5 Tester Channel Assignment [from Ref. 5] 



(2) ADAPTOR Section. The ADAPTOR section is the 
only optional section within the . tpp file. This section 
allows the GR-125 user to specify the Device Adaptor Beard 
(DAB) and Tester Adaptor Board (TAB) to be used with the test 
program. [Ref. 5:p. 4-12] 

(3) Test Pattern MODULE. This section of the .tpp 
file contains the actual test vector pattern elements. These 
elements define whether a pin functions as a driver for 
stimulus or a comparator (monitor) for response. A test 
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pattern MODULE section is mandatory. The drive and compare 
state information (used by the tester to sequence the DUT 
through the functional table) is placed here using the values 
specified in the manufacture's data book. Note that these 
pattern elements are then stored in memory behind each tester 
pin. Valid test pattern elements are listed in Table II. 
"Drive" indicates the stimulus applied to the input pins by 
the GR-125. "Monitor" indicates the sensing condition of the 
output pins . 

Table II GR-125 VALID TEST PATTERN ELEMENTS 



Pattern Vector Element 


Explanation 


0 


Drive low, neglect response 


1 


Drive high, neglect response 


X (or .) 


Driver off, neglect response 


L 


Driver off, monitor low 


H 


Driver off, monitor high 


T 


Driver off, monitor tri-state 


N 


Drive low, monitor low 


Y 


Drive high, monitor high 


Z 


Drive low, monitor high 


U 


Drive high, monitor low 


K 


Klunk (CLOCKMODE only) 


C 


Clock (CLOCKMODE only) 


i 


1 in Alternate format (CLOCKMODE only) 


o 


0 in Alternate format (CLOCKMODE only) 


? 


Repeat previous state 


- (dash) 


Hold pin state 



(a) Fermat. Three field entries are required 
to make a valid test pattern: MODULE, PATTERN, END. The 
MODULE input provides for a name field associated with this 
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section of the . tpp file. The PATTERN entry stores the actual 
test vector patterns. A test vector pattern has a pin control 
field which contains a pattern vector element for each device 
pin. Proper syntax requires test vector patterns to be 
buffered by slashes "/"• Refer to Figure 9. Note, the number 
of elements must be equal to the number of columns listed in 
the PINDEFS section of the .tpp file. Embedded spacing is 
ignored by this syntax. Ref 5 discusses four optional fields 
which can also be added to these pattern vector elements. 
[Ref. 5 : p . 4-14] 



/1 10010 HLHLLH/ 



Figure 9 GR-125 Sample Test Vector Pattern 

(b) Include statement. A special use of an 
INCLUDE statement permits the user to input a large test 
vector pattern code without having to retype each pattern 
element into the .tpp ASCII text file. The INCLUDE statement 
actually helps to modularize test vector patterns. This 
statement will be used to input a test vector file translated 
from a CAD simulation file. Chapter IV of this thesis will 
concentrate on this translation process. 
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b. Parameter Specification File 

The parameter specification file is also composed 
of data taken from a chip manufacturer's data handbook. This 
data is then used to test the DC parametrics and AC timing of 
a DUT. Data input into this file can occur via two methods. 
The first method utilizes custom Programming Screens which 
prompt the user for data input. The second method for 
inputting data into the parameter specification file does not 
use menu driven screens support. This method uses a simple 
ASCII text file format generated by the user from any text 
editor. Note, however, that the input data is in the same 
format for both methods. 

(1) Programming Menu Screens. Programming Menu 
Screens are provided by the GR-125 which allow the user to 
enter data for a particular device of interest. These screens 
work in coordination with the test pattern vectors listed in 
the . tpp file. The Programming Menu Screens are subdivided 
into five categories. Refer to Table III. This section will 
discuss the primary purpose of each of these five categories. 
Furthermore, every screen contained in these major categories 
will be listed for easy reference. Refer to Ref 5 for a 
detailed description of each individual screen. 
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Table III GR-125 PROGRAMMING MENU SCREENS 
(CATEGORIES) 



Category 


Function Key 


DEVICE DESCRIPTIONS 


"F6" 


ANALOG DATA SETS 


*F7" 


TIMING DATA SETS 


r F8' 


VECTOR TRUTH TABLE 


•FI 0" 


TEST OPERATIONS 


"F9* 





) 



(a) Device Descriptions. The Device 
Descriptions screens make up the bulk of the DUT parameter 
specification file. The screens listed here describe the 
device and test plan, including such parameters as package 
size, device technology, pin types, pin names, pin condition 
sets, pin test sets, etc. Table IV lists the screens located 
in this category. [Ref. 5:p. 2-4] 

(b) Analog Data Sets. The Analog Data Sets 
screens category defines the force and measurement levels used 
in functional and parametric testing. Supply voltage and 
current limits are also specified in these screens. Finally, 
all of the drive and compare pin levels for the functional 
tests are input during this set of screens. Table V lists the 
screens located in the category. [Ref. 5:p. 2-23] 

(c) Timing Data Sets. The Timing Data Sets 
screens category provides a wide range of timing information. 
Period and edge times defining the test program vectors are 
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Table IV DEVICE DESCRIPTIONS CATEGORY 



( DEVICE DESCRIPTIONS [F6] \ 

o Device Adaptor Pin Mapping 
o Pin Condition Set 
o Pin Test Set 



entered here. The resolution of the timing edge is determined 
by the largest period used for the test. Additionally, this 
category of screens provides a mechanism for assigning the 
formats and edge selections used for each pin condition set. 
Finally, several screens in this category produce a pictorial 
and/or tabular representation of the timing relationships of 
various input waveforms. Table VI lists the screens found in 
this category. [Ref. 5:p. 2-33] 

(d) Vector Truth Table. The Vector Truth Table 
screens are used to edit data located in the test vectors 
memory. Changes can be temporary or made permanent by editing 
the source file. This set of screens is used in conjunction 
with a special GR-125 diagnostic tool, "Learn". The function 
of this special output is covered later in this chapter. 
Table VII lists the screens found in this category. [Ref. 5:p. 
2-47] 
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Table V ANALOG DATA SETS CATEGORY 



[ ANALOG^ DATA SETS [F7] 




o Default Pin Levels 
o Pin Levels Set 
o Power Supply Levels Set 
o Load Relay Set 



(e) Test Operations. The Test Operations 
screens provide the user with the capability to describe how 
a particular test is to be performed. Each type of test 
represents a particular AC or DC parameter that the GR-125 
test system can measure. In summary, the screens in this 
category allow the user to modify various parameters 
associated with the test categories defined by the GR-125. 
These test categories will be addressed in the Test Execution 
phase discussion later in this chapter. Table VIII lists the 
screens found in this category. [Ref. 5:p. 2-53] 

(2) ASCII Text File Format. An alternate method of 
inputting information into the parameter specification file is 
through a direct ASCII text file as shown in Figure 6. This 
method may prove to be a more streamed-line approach by 
bypassing the Programming Screens menus; however, the required 
data input is the same for both processes. Appendix A of 
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Table VI TIMING DATA SETS CATEGORY 



( TIMING DATA SETS [F8] ; 




o Timing Array Set 
o Edge & Format Set 
o Timing Waveforms 
o Timing Data Table 
o Timing Data Sets(Combined) 



(Ref. 5) presents detailed information on the syntax required 
for this method of data input. 

2. ASCII To Binary Translation Phase 

Recall that the two major files produced during the 
Data Input Phase of the GR-125 test procedure were in an ASCII 
text format. However, the GR-125 requires that these ASCII 
input files be translated into machine- coded binary files for 
proper tester implementation. This translation process is 
accomplished through the use of two separate compilers within 
the GR-125 test system. 

a. Test Pattern Processor (TPP) Compiler 

The TPP compiler translates the . tpp ASCII text 
file into a machine- coded binary Vector Truth Table (.vtt) 
file. The .vtt file is actually used to perform the machine- 
coded functions specified in the .tpp file. The user must 
compile the .tpp file prior to testing. Table IX illustrates 
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the command line entry required to compile the . tpp file. 
[Ref. 5] 

Jb. ASCII to Par (ATP) Compiler 

The ATP compiler translates the parameter 
specification file (ASCII text file format) into a machine- 
coded binary parameter specification (.par) file. Table X 
illustrates the command line entry required to compile the 
ASCII formatted parameter specification input file. Note, 
however, that the parameter specification input file produced 
through the Programming Menu Screens does not require a 
separate compilation process. Refer to Figure 6. Once data 
is entered into an individual Programming Menu Screen, the GR- 
125 internally compiles it into a binary .par file. 

Table VII VECTOR TRUTH TABLE CATEGORY 



( VECTOR TRUTH TABLE [F10J , 




o Truth Table Edit 
o Truth Table Column Mapping 
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Table VIII TEST OPERATIONS CATEGORY 



f TEST OPERA TIONS [F9J 

o Test Operation 
o Vector Set 
o Bin Mapping & Control 
o Binning Sequence 



Table IX TPP COMPILER (COMMAND LINE ENTRY) 



prompt > tpp filename one.tpp 



Table X ATP TRANSLATOR (COMMAND LINE ENTRY) 



prompt > atp filenametwo.atp 



3 . Test Execution Phase 

Test execution in the GR-125 is designed and initiated 
by the system user through the "system test menu screens". 
These screens are actually a series of menus similar to the 
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Programming Menu Screens used to create the .par file. These 
system test menu screens provide a convenient method for 
configuring the GR-125 tester for a test operation. This 
configuration determines which part of a test program will be 
executed as well as establishing which type of format the 
output produces. Furthermore, this series of menus guides the 
user through a decision-making and data selection process. 
Modifications to these screens can be temporary for current 
testing or made permanent by overwriting the program or 
creating a copy. 

The system test menu screens described above can be 
organized into three broad categories: Test Execution, Results 
Display, and Input/Output. The following paragraphs will 
outline the actual screens in each of these categories. Due 
to the emphasis on the overall testing procedure, this section 
will not discuss every detail of each individual screen. 
However, specific references to the applicable technical 
manuals will be made. 

a. Test Execution Menu Screens 

These screens provide the majority of control over 
the Test Execution Phase. Manipulation of these test 
execution menu screens actually determines the output format 
of test results. The usage of these screens can be defined in 
four categories. Refer to Table XI. Certain individual 
screens denoted by " (RSVD) " are for GENRAD usage only. 
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Table XI TEST EXECUTION MENU SCREENS 



DEBUGGING CONTROL [F14] 

TT 

v 



</ Characterization Control-Combined 
Charaderizaiion Control-Setup 
Characterization Control-Output 
Hardware Control-Calibration 
Debugging Control-Sys Debug (RSVD) 




Batch/Lot Test Control-Execution (RSVD) 
Wafer Test Control-Execution (RSVD) 

* Characterization Control-Execution 
i Device Sequencing Control-Execution 
Test Operation Control-Execution 
Hardware Control-Execution 



(ANALYSIS CONTROL |F1 2] ~ , 



Batch/Lot Test Control-Analysis (RSVD) 
Wafer Test Control-Analysis 
Characterization Control-Analysis 
Device Sequencing Control-Analysis 
Test Operation Control-Analysis (RSVD) 




« « 

v 



i- Master Output Control 
* Terminal Output Control 
t Printer Output Control 
Primary Datalogging. Control 
Secondary Datalogging Control 
Datalogging Header Inrormation 



OUTPUT CONTROL |F1 3] 



Batch/Lot Test Control-Output (RSVD) 
Wafer Test Control-Output (RSVD) 
Characterization Control-OutDut 
Device Sequencing Control-Output 
Test Operation Control-Output 



* Screens also located in Characterization Control -Combined screen [ J ] 
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(1) Debugging Control . The screens in this 
category are used to set up the GR-125 tester to perform a one 
dimensional (ID) or two dimensional (2D) plot of various 
current, voltage or timing parameters. These engineering 
characterization (i.e. "shmoo") plots will be discussed in the 
Test Results Phase portion of this chapter. Additionally, the 
hardware control screen allows the user to vary the times for 
system calibration. Note, the GR-125 takes approximately 4 to 
10 minutes for a full system calibration. [Ref. 4:p. 2-22] 

(2) Execution Control. The execution control 
screens provide two major functions in the test execution 
procedure. First, the decision to perform a single test or 
multiple tests is made within this set of screens. Secondly, 
the specific type of test results desired for each test is 
annotated. Specif ically , these results options include 
pass/fail, full tabulated results, special plots, etc. These 
test result options will also be covered in detail in section 
4 of this chapter. [Ref. 4:p. 2-38] 

(3) Analysis Control. The analysis control set of 
screens were designed to keep track of statistical failure 
rate data during high volume production testing. As a result, 
this particular subcategory of test screens are not required 
for individual component testing. [Ref. 4:p. 2-48] 
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(4) Output Control. All of the output control 
screens are reserved for use by GenRad, Inc. except for the 
specific Characterization Control -Output screen. However, 
this screen is an identical duplicate screen listed in the 
Debugging Control category of system test screens. Therefore, 
the screens in this output control subcategory are presently 
not required for individual component testing. [Ref. 4:p. 2- 
55] 

(5) Datalogging- Control. The screens located in 
this category perform three major functions. First, the user 
must determine the distribution of data desired during 
testing. Secondly, the selection of the Terminal Output 
Control screen establishes the format of the test data 
outputted to the system terminal. Finally, the Datalogging 
Output screen is used for the accumulation of test result data 
for a statistical evaluation of long term trends. [Ref. 4:p. 
2-63] 

In summary, the Test Execution Menu Screens only 
require the user to manipulate the Debugging Control, 
Execution Control and Datalogging Control categories of 
screens. This condition will exist until a software 
modification is installed to the GR-125 test system. 
Additionally, note that the asterisks "*" in Table XI annotate 
five separate screens which are conveniently collocated in one 
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combined screen. This utility saves the user a great deal of 
time during the screen editing process. 

b. Results Display Menu Screens 

These result display screens contain the results of 
the most recent test performed. These screens provide the 
user with a real-time display within the test format desired. 
Table XII illustrates the screens available in this category. 
[Ref. 5 : p . 2-112] 



Table XII GR-125 RESULT DISPLAY MENU SCREENS 



(RESULTS DISPLAY [F20p 




o Batch/Lot Test -Results 

o Wafer Test -Results 

o Characterization (Plot) -Results 
o Characterization (Prod) -Results 
o Device Sequencing -Resuits 
o Test Operation 
o Vector History RAM 
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c. Input/Output Menu Screens 

The Input/Output (I/O) Menu Screens provide the 
user with file manipulation and screen configuration control. 
These screens help to stream-line the testing process by 
giving I/O control to the user. Table XIII shows the 
organization of these screens. 

Table XIII GR-125 INPUT/OUTPUT MENU SCREENS 




(1) File System Control. The File System Control 
screens provide a broad range of user functions. The Program 
Load screen provides the initial starting point for the 
testing process. This particular screen allows the user to 
load a specific test file for editing or test execution. 
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Additionally, this set of screens provides a means for storing 
modifications made to an existing test file. Finally, this 
set of screens allows the user to manipulate other UNIX files 
while still within the test operation "mtest" mode. [Ref. 4:p. 
2-10] The "mtest" mode is the application level above UNIX 
for GR-125 operation. 

(2) Screens Configuration. The Function Key 
Mappings screen located in this set of screens allows the 
user to define SHIFT Function keys on the VT220 keyboard. 
Once a key is defined, the user can call a screen of interest 
directly. In essence, this capability offers the convenience 
of avoiding menu prompts and therefore, saving setup time. 
[Ref. 4 : p . 2-89] 

4. Test Results Phase 

The Test Results Phase allows the user to consider 
which type of output result he desires from a fully edited 
test program. The GR-125 produces an output in one of three 
categories of test results. The three categories consist of 
a pass/fail output, actual measured values, and a pair of 
special diagnostic functions. This section will discuss each 
of these categories. Particular emphasis is given to how to 
edit the previously discussed system test screens in order to 
achieve a desired test result. 
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a. Pass/Fail Results 



The pass/fail mode of testing provides a Go/No-Go 
test result. This pass/fail mode requires just two test 
screens to be edited in the Test Execution Phase. Recall that 
the Characterization Control - Combined screen actually contains 
five separate screens. Table XIV provides a summary of 
entries required to obtain a pass/fail result. 



Table XIV PASS/FAIL MODE (REQUIRED SCREEN ENTRIES) 



Function 

key 


Screen Name 


\ 

Required Entry 


F1 1 


Test Operation Control-Execution 


[Pa$$/Fail Mode) 


F14 


Characterization Control-Combined 
Characterization Control-Execution 
Device Sequencing Cnti-Execution 
Master Output Control 
Terminal Output Control 
Printer Output Control 


[Product Testing] 

[Execute Binning Sequence) 
[Console; Test Op level] 
[Display Test System stats) 
[Print Test System stats) 


v 




J 



b. Actual Measurement Results 

In addition to a Go/No-Go test, the GR-125 can 
produce the actual measurements obtained during the testing 
process. Actual floating point values can be obtained for 
tests which involve AC and DC parametric measurements. 
Exceptions to this rule arise for tests which require only a 
pass/fail result such as a simple functional test. Section C 
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of this chapter will discuss the various types of tests the 
GR-125 is capable of doing. As with the pass/fail result, 
only two test screens require editing. Table XV provides a 
summary of the entries required to obtained an actual measured 
result . 

Table XV ACTUAL MEASURMENT (REQUIRED SCREEN ENTRIES) 



/ 

Function 

key 


Screen Name 


Required Entry 


F11 


Test Operation Control-Execution 


[Full Results Mode] 


F14 


Characterization Control-Combined 
Characterization Control-Execution 
Device Sequencing Cnti-Executlon 


[Product Testing] 

[Reform Only Specified Test 
•list specific test # here 1 




Master Output Control 
Tormina’ Output Control 
Printer Output Control 


[Console; Test Op level] 
[Display Summarized Resit] 
[Print Summarized Results] 


V 




_ _ _____ _ J 



c. Special Functions 

The GR-125 test system provides two special 
diagnostic functions in the Test Results Phase of the Test 
Programming and Execution Methodology. These special 
functions give the user some reverse engineering capability. 
By using these two special functions, an engineer can plot 
various engineering characteristics data as well as determine 
a chip's functionality to a certain extent. 
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(1) "Shmoo" Plots. Test: execution screens can be 
edited to produce a detailed ID or 2D engineering 
characterization (i.e. "shmoo") plot. A wide variety of 
values can be plotted on a set of labeled axes. These values 
include current levels, voltage levels and timing data. An 
example of a 2D "shmoo" plot is given in Figure 10. Note, the 
"shmoo" plot can only be generated by executing a simple 
functional test. To obtain a "shmoo" plot, a total of four 
test execution screens must be edited. Table XVI summarizes 



the entries required to obtain a "shmoo" plot. [Ref. 4:p. 2- 
22 ] 




(2) "Learn" Function. The "Learn" function also 
produces a reverse engineering capability. This function 
allows a user to determine the functionality of a specific 
chip. In essence, given the input test vector patterns, the 
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GR-125 will produce the output response pattern. Therefore, 
the chip function can be determined through a comparison of 
the input stimulus and the expected output response of the 
test vector patterns. The first step in executing the "Learn" 
function is to retrieve the Truth Table Edit screen (VT220 
function key "FlO") . Next, replace all the output test vector 
elements in the simple functional test to a "L", "H", or "X" . 
Next, retrieve the Test Operation screen (VT220 function key 
"F9") for the simple functional test operation. With the 
curser placed on the word "Simple", toggle the space bar to 
get the desired "Learn" function. Once this editing is 
complete, execute the testing sequence. No special test 
screen editing is required. Upon completion of the test, 
return to the Truth Table Edit screen and record the new 
output vector element values. [Ref. 5:p. 2-64] 

C. TESTING CAPABILITIES SUMMARY 

The GR-125 hardware test system performs many different 
types of tests. This section will briefly describe each of 
the major test areas. 

1. Functional Tests 

A functional test uses test vector patterns to cycle 
a DUT through its truth table sequence. After applying an 
input stimulus pattern, the GR-125 compares the DUT's output 
pattern with its expected output pattern. A successful 
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Table XVI 



"SHMOO" PLOT (REQUIRED SCREEN ENTRIES) 



r 

Function 

key 


Screen Name 


Required Entry 


F1 1 


Test Operation Control-Execution 


[Full Results Mode] 


F14 


Characterization Control-Combined 
Characterization Control-Execution 
Device Sequencing Cnti-Executlon 


[1 or 2 Dimensional) 

[Reform Only Specified Test 
-list function test # here I 


F14 

F14 


Master Output Control 
Terminal Output Control 
Printer Output Control 
Characterization Control-Output 
Characterization Control-Setup 


[Console; Char, level) 
[Display Summarized Resit) 
[Print Summarized Results] 

[ labte CC aixyor 'Y' axis ] 

[ select "TlmfrHj Array* or ’Power 
St*>pfy* or *Pin Level#* ] 


V 




) 



functional test requires a successful comparison of these 
output patterns. [Ref. 3:p. 1-44] 

2. Power Supply Tests 

The power supply test measures the current drawn from 
a selected power supply when the DUT is operating in either a 
static or dynamic state. [Ref. 3:p. 1-53] 

3. DC Parametric Tests 

Various tests for dc parametrics determine dc 
electrical characteristics by current and voltage 
measurements. These test can be classified as input or output 
dc parametric tests. [Ref. 3:p. 1-57] 
a. Input DC Parametric Tests 

(1) 111 Test. Leakage current is measured at a DUT 
input pin while forcing a logic low voltage. 
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(2) lih Test. Leakage current is measured at a BUT 
input pin while forcing a logic high voltage. 

(3) Vik Test. Voltage is measured at a DUT input 
pin while forcing a current. 

b. Output DC Parametric Tests 

(1) Iol Test. This test measures the DUT drive 
current at an output pin set low while forcing a logic low 
voltage . 

(2) Ioh Test. This test measures the DUT drive 
current at an output pin set high while forcing a logic high 
voltage . 

(3) Vol Test. This test measures the voltage at a 
DUT output pin while forcing the specified current with the 
device in the low state. 

(4) Voh Test. This test measures the voltage at a 
DUT output pin while forcing the specified current with the 
device in the high state. 

(5) Iozl Test. This test measures the current at 
a DUT output pin while the pin is in the tri-state condition 
and while forcing a logic low voltage. 

(6) Iozh Test. This test measures the current at 
a DUT output pin while the pin is in the tri- state condition 
and while forcing a logic high voltage. 
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(7) Ios Test. This test measures the current at a 
DUT output pin while the pin is in the logic high state and 
while forcing a zero voltage. 

4. AC Functional Tests 

AC functional tests perform certain ac measurements on 
the DUT. These measurements include setup time, propagation 
delay, pulse width, hold time, and transition time. [Ref. 
3 : p . 1 - 6 6 ] 

5. Contact Tests 

Contact tests can be classified as continuity tests. 
These tests check that a non- shorted and non- open path exists 
from a given tester pin through the DUT to ground or a power 
supply connection. During testing, all of the ground pins on 
the DUT are connected to ground, and all of the power supplies 
to the DUT are set at 0 volts. [Ref. 3:p. 1-66] 
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III. CAD SIMULATION ENVIRONMENT 



The CAD simulation environment provides the first major 
testing platform in the digital design process. Once a 
schematic design is obtained, a series of simulations 
determine the functional characteristics of the design. This 
process is repeated until a desired functionality is achieved. 
Figure 11 illustrates this process. When a successful 
simulation is obtained, a graphical plot and simulation output 
file are produced. The output file contains all of the 

stimulus and response information observed in the graphical 
plot. Additionally, this simulation output file is produced 
in an ASCII file format. Chapter IV of this thesis will 
discuss how to change the test vector information found in 
this simulation output file into the . tpp file format required 
by the GR-125 tester. 

A. SIMULATION OVERVIEW (MENTOR GRAPHICS) 

Because of availablity, this thesis utilized the Mentor 
Graphics IDEA Series Version 7.0 CAD package for analysis. 
CAD simulation incorporates two basic design steps: 

• Schematic Capture 

• Test Simulation 
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A short discussion of these two design steps will illustrate 
the framework of the design process. The objective of this 
simulation overview is to provide a brief background to 
simulation within the CAD environment. 




Figure 11 CAD Design/Simulation Process 



1. Schematic Capture 

The first step in the design simulation process is to 
generate a schematic diagram of the desired digital component. 
This process is known as "schematic capture." Schematic 
capture is accomplished on an IDEA Series workstation through 
the use of a network editor and a symbol editor. The network 
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editor (NETED) allows a designer to create hierarchical 
(multi-level) designs using a top-down approach. The symbol 
editor (SYMED) works with the NETED. SYMED allows the 
designer to draw and edit component symbols that can be placed 
on NETED schematic sheets. These symbols can represent basic 
design elements such as logic gates, transistors and off-the- 
shelf integrated circuit (IC) components. Together, these two 
schematic editors provide the resources for producing a 
testable design. [Ref. 6:p. 1-1] 

2. Test Simulation 

Once a designer has completed the schematic editing 
phase, he enters the actual testing procedure - simulation. 
As discussed previously, CAD simulation enables a designer to 
check the functionality of a component design. By defining 
input stimuli and observing the output responses, the 
designer's simulation is identical to the simple functional 
test portion of the GR-125 hardware tester. Quicksim is the 
simulation program used to perform the actual simulation. 
This CAD software tool is also included in the Mentor Graphics 
IDEA Series (v 7.0) package. 

Quicksim is an interactive logic simulator that allows 
a designer to verify the functionality of the designs produced 
with SYMED and NETED, the schematic capture tools. Quicksim 
is a 12 -state, timing- wheel simulator that can simulate MOS, 
TTL, and ECL logic. With Quicksim one can apply stimulus to 
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the design, run the simulation, analyze the results, and then 
modify the design based on these results. Stimulus is defined 
as the input stimuli and the expected output results data. 
Basically, a stimulus consists of a set of test vectors as 
discussed in chapter II. [Ref. 7:p. 1-1] 

Quicksim accepts and produces a variety of stimulus 
data. This data includes various graphical and text file 
formats. Figure 12 illustrates the variety of Quicksim' s 
input and output data. The input is the stimulus as defined 
above. The output contains the actual results of the 
simulation. Next, one specific output file, the List Window 
File will be discussed. 




Figure 12 QuickSim Input/Output Files [from Ref. 7] 
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B. SIMULATION OUTPUT FILE 

The simulation output file, List Window, contains all of 
the stimulus and response data from a simulation session 
executed within the Quicksim environment. The command "List" 
is used to create the List Window file. Figure 13 shows a 
typical List Window file. Nocice that this file contains 
three sections of information: time, pin labels, and pin 
values. The following paragraphs will briefly discuss the 
structure of these specific sections. 
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Figure 13 QuickSim List Window Display [from Ref. 7] 
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1 . 



Structure 



a. Time Values 

Specific time values occupy the first column of the 
List Window file. These times are actually user scaled units. 
A designer can scale these units to any desired value. For 
clarity, the user time unit is scaled to nanoseconds 
throughout this thesis. Note that a new time value is 
generated at every instance an input or output pin changes 
state. This condition allows a designer to observe how long 
a component takes to reach a desired output state. This time 
is defined as delay time. 

b. Pin Labels 

The pin labels section of the List Window file 
appears at the very end of the file. These labels actually 
break the List Window into separate columns. Each column is 
reserved for a specific input or output pin value. The first 
column, reserved for the time values, provides the one 
exception to this rule. By convention, the input pin values 
occur prior to the output pin values. 

c. Pin Values 

The pin values section consists of the various 
columns of single digit numbers located directly above the pin 
labels. These pin values can contain one of three separate 
signal levels, ("0", "1", "X"). Table 17 describes each of 
these signal levels. 
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Table XVII QUICKS IM SIGNAL VALUES 
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In summary, once a successful simulation is complete, 
a designer can obtain an ASCII file containing all of the List 
Window data information. This new ASCII simulation output 
file is generated by invoking the Quicksim command summarized 
in Table XVIII. The sim_output file now contains all of the 
stimulus and response test vector data in an ASCII format. 
Chapter IV of this thesis will show how to translate the ASCII 
data from the sim_output file into the . tpp ASCII file format 
required by the GR-125 tester. 

Table XVIII QUICKSIM WRITE LIST ENTRY 

prompt > WRite List sim output 
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2. Design Example (74S181 ALU) 

An example can better illustrate a typical simulation 
output from the Quicksim environment. The 74S181 Arithmetic 
Logic Unit (ALU) provides an excellent design example for 
analysis. In order to illustrate the CAD simulation data 
discussed previously, this design example will be introduced 
in three areas: 

• Circuit Description 

• Input Stimulus 

• Output Simulation File 

a. Circuit Description 

The 74S181 ALU performs binary arithmetic or logic 
operations on two 4 -bit words. Figure 14 illustrates the 
connection diagram. Additionally, Table 19 describes the pin 
designations. These arithematic operations are selected by 
the four function select lines (SO , SI , S2 , S3 ) , and it includes 
addition, subtraction, decrement and straight transfer. The 
internal carries must be enabled by applying a low level 
voltage to the carry_in (Cn) . A full carry look-ahead scheme 
is available for fast carry generation by means of two 
cascaded outputs (P,G). [Ref. 8:p. 5-100] 

Jb. Input Stimulus 

The input stimulus to the 74S181 is applied through 
a .misl file (Refer to Figure 12). For this particular 
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example, the input pin values are forced to change every 10 
nanoseconds. Figure 15 shows a portion of the 74S1S1 .misl 
file . 



ourmjTz 




Figure 14 74S1S1 ALU Connection Diagram 

c. Output Simulation File 

After the stimulus data is entered and the List 
Window screen is set up within the Quicksim environment, the 
simulation is started. The "Write List" command is executed 
at the end of the simulation. The successful completion of 
each of these steps produces an ASCII formatted simulation 
output file. Figure 16 shows a portion of the simulation 
output file obtained for the 74S181 design example. 
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Table XIX 74S131 PIN DESIGNATIONS [from Ref. 8] 
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Figure 15 74S181.misl Stimulus File (partial) 
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IV. SOFTWARE TRANSLATION METHODOLOGY 



A. DISCUSSION 

This thesis has addressed two separate digital testing 
environments. As discussed in chapter III, the GR-125 
hardware tester enables a designer to perform many different 
types of tests including a functional test. Additionally, 
chapter IV described how the QuickSim CAD simulator offers a 
functional test capability within the simulation test 
environment. A close comparison of the functional test 
requirements within each of these environments reveals an 
interesting similarity: the stimulus/response data required 
for each test environment contains the same general 
information. The only difference lies in its structural 
format . 

As discussed in chapters II and III, the stimulus required 
for both test environments is composed of test vector 
elements. Although these test vector elements contain 
essentially the same stimulus information, their input format 
is quite different between the GR-125 and the QuickSim test 
environments. Recall that the GR-125's test vector stimulus 
is located in the ASCII formatted . tpp file (refer to Figure 
7) . In contrast, test vector stimulus for the QuickSim 
simulator originates in a .misl file (Figure 15) . After 
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simulation these test vector stimulus elements and their 



response patterns are recorded in the list window .list file 
(Figure 16) . 

An enormous amount of time and effort is required to 
generate a set of stimulus test vector patterns. These 
patterns can easily exceed thousands of lines of data 
elements. Furthermore, manually copying these test patterns 
into two formats can lead to many inadvertent editing errors. 
Accordingly, finding a way to make these two test environments 
compatible with each other is extremely advantageous. As a 
result, developing a software translation program will 
effectively link the digital simulation environment with the 
GR-125 hardware tester environment. This process will 
translate the test vector patterns generated by the QuickSim 
simulator into an acceptable format for the GR-125 . tpp file. 
The desired translation process is illustrated in Figure 17. 

The software translation procedure described above reads 
an input file, performs various editing, and produces a 
desired output file. This process is actually performing the 
function of a mini compiler or interpreter. This chapter will 
discuss how various software tools can be used to build such 
an appropriate translator. Finally, chapter V will present 
the actual translator results. 
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Figure 17 Test Vector Translation Procedure 
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B. INTERPRETERS AND COMPILERS 



As discussed above, a compiler and/or interpreter are the 
heart of any software language translation. A compiler inputs 
a program and converts it into a set of instructions that can 
be performed by the computer. The input for a compiler 
typically spans multiple lines. In comparison, an interpreter 
acts immediately on the user's typed input, one line at a 
time. Compilers and interpreters are very similar in how they 
process input and generate output; therefore, this thesis will 
use the term compiler to mean both interpreter and compiler. 
The input to a compiler is a character stream. Alternately, 
the output of a compiler is an action or series of actions, 
possibly as simple as printing an output identical to the 
input . 

The compiler performs its function in three separate 
stages : 

• lexical analysis 

• parsing 

• actions 

The first stage, lexical analysis, scans the input stream and 
converts various sequences of characters into groups known as 
tokens. Tokens are groups of characters predefined by the 
compiler writer. In the second stage, a parser reads these 
newly created tokens and assembles them into language 
constructs. The constructs of a language actually describe 
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how expressions, identifiers, and keywords can be combined to 
form statements. For example, the "if-then" statement in Ada 
is a language construct. Finally, in the third stage of a 
compiler, actions were taken once a token is matched. Every 
stage is important. The completion of one stage provides the 
input for the next stage. However, in less complex 
applications, the action stage can immediately follow the 
lexical analysis stage. Figure 18 summarizes these stages. 
A programmer could write a custom analyzer or parser in any 
computer language. However, there exists some special C based 
UNIX tools which offer superior flexibility and capability in 
compiler design. [Ref. 9] 




Figure 18 Compiler Processing Stages 
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C. UNIX TOOLS OVERVIEW 



Special UNIX tools exist which makes compiler design 
rather simple and straight forward. This chapter will analyze 
two specific UNIX utilities which can be used to design a 
translation program: 

• Lex (Lexical Analyzer Generator) 

• Yacc (Yet Another Compiler Compiler) 

Lex and yacc are specifically designed for writing compilers. 
These tools create C routines that analyze and interpret an 
input stream of characters to produce a desired output 
product. Both of these utilities were developed at Bell 
Laboratories in the 1970's. Additionally, lex and yacc have 
been standard UNIX utilities since Version 7. Figure 19 
provides a graphical comparison of the power of various tools 
in the UNIX programming toolkit. Note that lex and yacc are 
powerful but still provide a programmer with tools not so 
complex as C itself. [Ref. 9:p. xiv] 

D. LEXICAL ANALYZER GENERATOR (LEX) 

1 . Background 

Lex performs the lexical analysis function of a 
compiler. Specifically, lex reads an input file containing 
regular expressions for pattern matching and generates a C 
routine that performs lexical analysis. As discussed 
previously, this routine will read a stream of characters and 
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match predefined sequences as tokens. These input streams are 
byte streams in UNIX. Lex, therefore, breaks these byte 
streams up into tokens. Once these tokens are assembled, lex 
can choose between two options: 

(1) pass the tokens to yacc for future action 

(2) perform immediate action based on a token match 
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Figure 19 UNIX Toolkit Hierarchy 



2. Lex Specification Format 

The structure of a lex program is known as a lex 
specification file. Figure 20 delineates the three sections 
which form a full or complete lex specification. The first 
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and last sections are optional entries. Consequently, a lex 
specification can actually be composed of only the rules 
section. Although each section will be addressed, only the 
rules section will be covered in detail. By convention, the 
lex specification is created in a file using a ".1" suffix. 




Figure 20 Full Lex Specification Format 



a. Rules Section 

The main section of a lex specification is composed 
of a set of rules. Two percentage signs "%%" are a required 
symbol to indicate the start of this section. Each rule 
contains a regular expression that is matched against an input 
stream. Once this match is made a specified action is taken. 
These pattern matching rules are expressed in UNIX regular 
expression syntax. Figure 21 illustrates a simple lex 
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specification with a single rule. In this rule "Navy" is a 
regular expression in which each character is interpreted 
literally. The action is composed of the C library function 
"printf". Basically, this lex specification states that if 
the token "Navy" is recognized in the input stream, then "Beat 
Army" is printed. Note, however, that if the input does not 
match any of the regular expressions explicitly defined in the 
rules, a default action is executed. This default action will 
copy the input to the output with no modifications made. 
Therefore, a lex specification with no specified rules will 
completely copy or echo the input to the output. 
Consequently, if a programmer wants to restrict the output, 
explicit rules must be written to match the input and then 
discard it. 




Figure 21 Lex Specification Rule 



A lex specification can actually be thought of as 
an input scanner which scans the input stream and executes a 
set of actions. This is the concept which will be implemented 
to develop the translator program in chapter V. The key to an 
effective input scanner is properly defining the regular 
expressions in the rules section. Analyzing a specific 
regular expression with specifically defined expression 
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operators will help to explain its usage. Table XX provides 
a simple example of a regular expression representing real 
numbers. These real numbers consist only of digits and 
decimal points. It is advantageous to break this regular 
expression into two parts for analysis. Looking at the second 
part first reveals: 

[0-9] + 

The brackets [] enclose a set of exclusive choices. A 
consecutive range of digits or letters within brackets can be 
abbreviated by the use of a hyphen. This particular 
expression matches any single digit from 0 to 9 . A plus "+" 
symbol means one or more of the preceding. Therefore, this 
part of the expression matches "2", "223", or any sequence of 
digits. Now, a look at the first part of this expression 
reveals : 

( [0-9] *\ . ) * 

The asterisk means zero or more of the preceding. 
Parentheses "()" are used to group an expression so that it 
can be modified as a single unit. As a result, the asterisk 
following the expression in parentheses makes the entire 
expression optional. Additionally, the asterisk following the 
" [0-9] " makes the digits preceding the decimal point optional 
as well. The dot "." normally is used to match any character 
except a newline "\n". However, in this example, a backslash 
"\" is used to make the dot be taken literally. Therefore, 
this part of the expression matches a decimal point preceded 
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by any sequence of digits. Table XXI provides a listing of 
the regular expression operators used in lex. For a more 
detailed discussion of the syntax required for regular 
expressions, refer to chapter 6 of Ref. 9. 

Table XX LEX REGULAR EXPRESSION EXAMPLE 

/ \ 

Numbers desired to match: 

223 

2.2 

2 

22.32 

Regular expression: 

( [ 0 - 9 ] * \ .) * [0 - 9 ]+ 

V ___ J 



b. Definition Section 

The definition section of a lex specification is 
optional. However, this section does allow a programmer to 
define simple macros for use in the rules section discussed 
above. For example, the regular expression expressed in Table 
XX could be defined in the definitions section as follows: 
real_num ([0-9]*\.)*[0-9]+ 

Therefore, the term "real_num" followed by an appropriate 
action would constitute a valid rule without having to rewrite 
the full expression. 
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c. User Routine Section 



The user routine section is also an optional 
section in the lex specification. This section can contain 
any valid C coded routines. Frequently, however, this section 
will have no code since the necessary routine will be provided 
by the lex library. This lex library is discussed in the next 
section on usage. 

Table XXI LEX REGULAR EXPRESSION OPERATORS [from 
Ref. 9] 



Character 


| Meaning 


. 


Matches any singie character (except newline). 


s 


Matches the end of the line as trailing context. 




Matches beginning of line, except inside [] when it means "comple- 
ment"^ 


[] 


Matches any of the specified characters. 


- 


Inside [], if it is not the hist or Last character, means "the range or. 


? 


The previous regular expression is optional (e.g., 10?9 is 109 or 19). 


* 


.Any number of repennons, including aero. 




.Any positive number of repennons, but not zero. 


1 


.Allows alternation ber^een two expressions (e.g., 101 11 matches 
10 or 11). 


0 


.Allows grouping of expressions. 


/ 


Matches an expression if followed by the next expressions 
(e.g., 10/11 matches 1011). 


( } 


Allows repetitions or substitutes a denmtion. 


< > 


Dennes a start condition. 



3 . Usage 

There are three steps required to run lex. Figure 22 
describes each of these steps. It is important to note that 
the lex.yy.c file, created in step 2, is not a complete 
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program. It contains a lexical analysis routine called 
"yylex" . Consequently , there are two ways to call yylex: 

• Supply a hand- coded main routine that calls yylex () 

• Integrate the lexical analyzer with a yacc- generated 
parser 

The second method of calling yylex () will be addressed in the 
next section on yacc. The actual translator program, which is 
developed in chapter V, will utilize a separate main routine 
to call yylex (). Finally, the program compilation in step 3 
requires the "-11" option. This compiler option is required. 
By invoking this "-11" option lex.yy.c is linked with the UNIX 
standard library "libl.a" . 

E. YET ANOTHER COMPILER COMPILER (YACC) 

1 . Background 

Recall that the second stage of a compiler process 
involves a parsing routine. Refer back to Figure 18. As 
mentioned earlier, the parser reads the tokens created by the 
lexical analyzer and assembles them into language constructs. 
These constructs will then be used to describe how 
expressions, identifiers, and keywords combine to form 
statements. Yacc performs the duty of a parser. Basically, 
yacc reads a specification file that codifies the grammar of 
a language and generates a parsing routine. This parsing 
routine will then group the tokens produced from a lexical 
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step 1 : Create a lex specification file 



step 2 



step 3 



Cl^spec_f/leT^ 

Run lex on the ".I" file 
prompt > lex lex_spec_file .1 

generates 




lex.yy.c file 



Compile lex.yy.c and any other 
related source files 

prompt > cc -o outfilel lex.yy.c -II 



Figure 22 Lex Usage Steps 



analyzer into meaningful sequences and take action as 
specified in the action routines. Figure 23 taken from Ref. 
9 describes the basic function of a parser. In summary, it is 
important to recognize the fact that a parser like yacc must 
have an associated lexical analyzer to provide it with tokens. 
Yacc will not function as a stand alone routine like lex. 

2. Yacc Specification Format 

The yacc specification format closely parallels the 
lex specification format. Figure 24 illustrates the three 
sections which form a full yacc specification. The 
declarations section and the grammar rules section are both 
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The lingua franca of a Pay Phone 



To understand what a parser does, let's describe it by 
analogy 7 to a pay telephone. To place a call, it costs 
20 cents, and that 20 cents can be paid using nickels and 
dimes. Each coin represents one token. The syntax of 
our language must state whai combinations of tokens 
make up 20 cents. The following rules describe these 
combinations: 




I a a a 
■ a a 
■■■ 
"" 



ii 

u 









For example, if the first com is a nickel and the second com is a dime, we do 
not yet have a valid combination, and to produce one, we need a third com that 
is a nickel. Each of these lines can be considered rules for producing a valid 
combination totaling exactly 20 cents. The "machine” is able to apply these 
rules by "ruling out” the ones that are no longer valid. For instance, if the hrst 
coin is a dime, we know that only the Last two rules can be applied. If the next 
coin is a nickel, then only the fourth rule is left to be applied on remaining 
input. Parsing, then, is the ability to recognize certain sequences of tokens. 



The above set of rules have the same action associated with them, which might 
be "connect caller.” We could write rules to recognize other tokens and to 
specify different actions. For instance, we might have a rule for pennies and 
slugs, dropping she token into the com return slot. Similarly, we could have a 
rule: 




and specify an action that returns the nickel and makes the connection. (This, 
of course, is not a real pay phone.) The set of rules constitute a grammar . In ( 
other words, a grammar describes the combinations of tokens that produce 
meaningful results. 



Figure 23 Parsing Description [from Ref. 3] 
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required for a complete yacc specification. By convention, a 
yacc specification file uses a ".y" suffix. 




a. Declarations Section 

The declarations section establishes the framework 
throughout the parser. The tokens and operators, which 
originated from the lexical analyzer, are defined here. The 
actual form of the token is declared as well as any other 
global variables that will be used. These token definitions 
describe all the possible tokens that the lexical analyzer 
will return to the parser. Recall, yacc was developed to help 
translate one software language into another. Any generic 
language will have text, comments, commands, numbers, etc. 
Therefore, tokens are used to define these different language 
elements. Table XXII shows a typical declaration in a yacc 
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.specif icatzion . As discussed above, che declaration section 
also defines the operators used in the parser. Table XXIII 
lists several keywords and their associated meanings which can 
be used in the declaration section. Refer to chapter 7 of 
Ref. 9 for additional information. 

Table XXII YACC DECLARATION ENTRY 



% token < val > NUMBER 
% token < text > COMMENT 
% token <cmd> COMMAND 
% token <text > TEXT 

\ J 



Table XXIII YACC DECLARATION SECTION 
KEYWORDS [from Ref. 9] 



% token 


Declare the names of tokens. 


^ left 


Denne left-associadve operators. 


bright 


Define right-associanve operators. 


% nonass oc 


Denne operators that may not associate with themselves. 


%type 


Declare the type of nonterminals. 


bunion 


Declare multipie data types for semantic values. 


% start 


Declare the start symbol. Default :s first in rules section. 


%prec 


.Assign precedence to a rule. 
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£>. Grammar Rules Section 



The grammar rules section of the parser is where 
all of the action in yacc takes place. As in lex, there are 
production rules followed by action statements. However, the 
rules section in yacc is quite a bit more complicated than 
lex. A complete grammar rule in this section is composed of 
three elements: 

• symbol 

• definition 

• action 

Figure 25 shows the format of a yacc grammar rule. 




Figure 25 Yacc Grammar Rule Format 

(1) Symbol. There are two types of symbols used in 
yacc: "terminal" and "nonterminal". A terminal symbol is an 
actual token or literal character that is recognized by the 
lexical analyzer. Conversely, a nonterminal is strictly 



70 



defined as a non- token. By convention, the names of 
nonterminal symbols are written in lower case letters while 
the names of terminal symbols are capitalized. These two 
symbols should not be confused with the symbol location in the 
left hand side of the grammar rule. Only a nonterminal symbol 
is allowed in this symbol location. Alternatively, the right 
hand side of the grammar rule, the definition location, can be 
made up of both terminal and nonterminal symbols. 

(2) Definition. The definition portion of a yacc 
grammar rule consists of zero or more symbols made up of 
terminal and nonterminal symbols. The syntax of this section 
is essentially a hierarchical structure which uses a top-down 
structure relating various terminal and nonterminal symbols. 
Table XXIV provides an example of how these various symbols 
interrelate. Recall that the capitalized words are tokens 
(i.e. terminal symbols). The first rule in this example 
states that a nonterminal symbol, "list", is made up of either 
an object or of a list and an object. Note the use of 
recursive definitions. The pipe " j" symbol is used as a union 
operator. Finally, the last rule in Table XXIV specifies that 
the nonterminal symbol number is either a NUMBER, a NUMBER 
with a plus "+" in front, a NUMBER with a minus in front, 
or two numbers separated by a decimal point " . " . 

The construction of this grammar clearly shows 
a bottom-up process. Each grouping is included in larger 
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groupings until there is a single top-level grouping that 
includes all other groupings. This top level language 
construct is referred to as the "start" symbol. In the sample 
of Table XXIV "list" is the start symbol. When the start 
symbol is recognized and there is no more input, then the yacc 
parser knows it has seen a complete program. [Ref. 9:p. 12] 
(3) Action. The action within a yacc grammar rule 
consists of one or more C language statements similar to a lex 
action statement. These actions are executed each time a 
corresponding rule is matched. Actions usually manipulate the 
values of tokens. 

Table XXIV YACC GRAMMAR RULE ELEMENTS 
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c. C Programs Section 



The C programs section of a yacc specification is 
composed of C coded routines. This section performs the 
identical function of the user routine section found in the 
lex specification. 

3 . Usage 

There are five steps to creating a yacc parser. 
Figure 26 describes each of these steps. 
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The y.tab.c file is not a stand alone routine similar to the 
lex.yy.c file. Step 5 of Figure 26 requires the "-ly" option 
in addition to the "-11" option. The order is important 
between the lex and yacc library extensions. The overall use 
of lex and yacc are summarized in Figure 27. 




ici . a 
iov . a 



Figure 27 Lex And Yacc Usage Summary [from Ref. 9] 
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4 . Flow Control Summary 

Lex and yacc have each been analyzed separately. 
However, the lexical routine created by lex, yylex, and the 
parsing routine created by yacc, yyparse, work together. 
Figure 28 illustrates the flow of control in lexical and 
parsing routines. 



evaluate 





Fig-ure 28 Lex And Yacc Flow Control [from Ref. 9] 



The main program invokes yyparse to evaluate whether the input 
is valid or not. Next, yyparse invokes the yylex routine each 
time it needs a token. The lexical routine reads the input 
stream and returns a token number to the parser for each token 
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it matches. The token number lets yacc know which token has 
been received. The token number corresponds to the ASCII 
value of each ASCII character (0 to 256) . Thus special user- 
defined tokens begin at 257. These special user-defined 
tokens are defined in the definitions section of a lex 
specification. Additionally, the lexical routine can also 
pass the value of the token using the external variable 
"yylval". Once the lexical routine has exhausted the input, 
it returns a "0" to the parser. If the parser has recognized 
the start rule, then the parser returns a "0" which means that 
the input is valid. If the parser receives a token number or 
a sequence of tokens that it does not recognize or if the 
lexical routine returns 0 (end of file) when the start symbol 
has not been recognized, then the parser returns 1, reporting 
a syntax error. [Ref. 9:p. 14] 

This chapter has described the software translation 
procedure by comparing it to a compiler process. The special 
UNIX tools, lex and yacc, provide ideal resources for building 
such a language translation program. Although lex and yacc 
work well together, lex is extremely powerful on its own. 
Lex's ability to both scan an input and take actions based on 
that input data makes lex an effective "stand alone" compiler 
system. As a result of this capability, lex alone will be 
used in chapter V to build an actual translator to modify a 
CAD simulator output file into the compatible format required 
by the GR-125 tester system. 
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V. TRANSLATOR DESIGN RESULTS 



Chapter IV discussed the benefit of developing a software 
translation tool to link the digital design environment with 
the GR-125 hardware tester environment. Additionally, a 
software translation methodology was presented incorporating 
special UNIX tools such as lex and yacc. This chapter will 
present the results of an actual translation process which 
provides a solution to the test vector incompatibility problem 
between these two test environments. After a brief overview, 
the structure, usage, and results of this translator program 
will be presented. 

A. OVERVIEW 

The overall objective of this translator program is to 
translate the test vector patterns generated by the QuickSim 
simulator into the structural format required by the GR-125 
. tpp file. The List Window file produced by the QuickSim 
simulator will provide the input for this translator. The 
output file produced from the translator will then be included 
in the GR-125 .tpp file (refer back to Figure 17) . Because of 
the extreme capability and flexibility of the lexical analyzer 
generator (lex) , this special UNIX tool alone will provide the 
backbone for this translator design. Furthermore, in order to 
maintain continuity for discussion, this translator program 
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will perform manipulations on the 74S181 ALU simulation files 
developed back in chapter III. The name of this translator 
program is "vector_map" . 

B . PROGRAM STRUCTURE 

The basic components of the translator program, 
vector_map, consist of a main program and a lex routine. The 
main program, vector_map.c, is a C based program which calls 
the lex routine, vector_map . 1 , to perform the token matching 
and corresponding execution functions. The lex routine is the 
heart of the vector_map translator. This section will discuss 
the composition of each of these two routines. 

1. Main Program (vector_map.c) 

The entire vector_map.c program is presented in Figure 
29. This main program performs two major functions: 

• provides a location for inputting the number of input pins 

• calls the lex routine 

The correct number of input pins are required by vector_map.l 
in order to function properly. As discussed in chapter IV, 
vector_map.c uses the function yylex() to call the lex 
routine . 

2. Lex Routine (vector_map . 1) 

As stated above, the lex routine does most of the work 
in the vector_map translator. Figure 16 presents a typical 
input file scanned by the vector_map.l routine. In order to 
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produce a test vector stimulus file compatible with the GR-125 
. tpp file format, three major alterations must be performed. 
Table XXV delineates these translation requirements. The 
vector_map.l routine , provided in Figure 30, scans different 
stimulus elements by keeping track of the number of spaces 
encountered. These spaces are defined as a " f ield_count " in 
this specific lex routine. 




As mentioned in chapter IV, every character a lex 
routine encounters on input will be copied directly to the 
output unless explicitly defined as a token with a 
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corresponding action statement. Consequently, the first 
requirement, listed in Table XXV, is satisfied by matching 
unwanted characters and/or character strings and deleting 
these matched tokens with a semicolon This action is 

accomplished in the last four lines of the vector_map.l 
routine . 

Table XXV "vector_map . 1 " COMPILATION STEPS 

1. Remove unwanted Characters 

2. Produce input vector pattern immediately followed 
by the final state output pattern 

3. Change output pattern elements "O' 1 and ”1" to 
"L" and "H" respectively 

l J 



Lex creates an external variable named "yytext" that 
contains the string of characters that are matched by the 
regular expression defining the token. Therefore, changing 
the value of this variable provides a solution to the third 
translation requirement of Table XXV. Because yytext is a 
string type variable, the C function "atoi" is used to convert 
it to an integer value prior to comparing it to the integer 
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Figure 30 "vector_map . 1 " Code 
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values 0 or 1 . The following code shows a portion of the 
vector_map . 1 routine which satisfies this translation 
requirement to change the output vector elements to a "H" or 
" L " : 



if (atoi (yytext ) == 0) { 

print f (" L"); 
break; 

} 

The second translation requirement listed in Table XXV 
poses the most challenging programming algorithym. A close 
observation of the 74S181.1ist file in Figure 16 reveals 
several output vector states for every set of input vector 
stimuli. These output vector elements change state until the 
end of a delay time is encountered. The delay times for the 
74S181 ALU chip in the simulator environment lasts 
approximately 6-7 nanoseconds. Although this intermittent 
state change information is interesting, it would confuse the 
GR-125 tester. The test vector elements placed in the GR-125 
. tpp file require a set of input stimulus elements followed by 
expected output result elements. If every test vector in the 
QuickSim .list file were put into the GR-125, the functional 
test would always produce a failed result. Accordingly, only 
the initial input stimulus elements followed by the final 
state output elements are chosen to form a valid test vector. 
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By using various "arrays" of input elements and "for" loops, 
this lex routine provides a look ahead capability to determine 
which set of input and output elements to record for an 
accurate test vector. 

C . PROGRAM USAGE 

The main program and lex routine must be compiled and 
linked to form a usable translator program. Table XXVI 
reviews these required steps. This section will address the 
usage of the newly developed translator program, vector_map. 

Table XXVI "vector_map" COMPILATION STEPS 



1. Input File 

As stated previously, the input file used by the 
vector_map translator is composed of the List Window file 
produced from the QuickSim simulator. This .list file must 



step 1 : Write lex specification > vector_map.l 



step 2 : Run lex: 

p renr, p t> lex vector_map.l 

step 3 : Compile and link with main program (vector_map.c) 



prompt > cc -o vector_map vector_map.c /ex.yy.c -// 
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have the input elements listed before the output elements. 
This requirement is easy to obtain since the programmer can 
order the list window in any desired way within the QuickSim 
environment. Secondly, the actual number of input pins must 
be known prior to invoking the translator program. The next 
section will discuss the placement of this input number. 

2 . Command Line Entry 

The command line entry required to obtain a valid 
test_vector_out file is illustrated in Table XXVII. Notice 
that this entry uses the UNIX tools cat and pipe " | " to funnel 
the input file through the translator to produce the valid 
output file. Additionally, the number immediately following 
vector_map is the required location for inputting the number 
of input pins. In this example, the number 14 represents the 
14 input pins in the 74S181 ALU chip. 

Table XXVII "vectorjmap" COMMAND LINE ENTRY 

Wnpo cat input_file.Iist I v&ctor_map 14 > test_vector_out 



D . RESULTS 

The output file created from the command line entry 
described above, contains input and output pin states in 
proper test vector pattern format. This . tpp file format was 
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discussed back in Figure 9 of chapter II. Figure 31 
illustrates the output file produced by invoking the 
vector_map translation program on the 74S181.1ist simulation 
file developed in chapter III. 

The final action required to fully link the CAD simulator 
and hardware tester environments is to include this newly 
created output file into the GR-125 . tpp file. Chapter II 
referenced the use of the "INCLUDE" statement in the PATTERN 
section of the .tpp file. Only one line is added to the 
existing .tpp file to incorporate this newly created output 
file. The additional line of code is placed in the PATTERN 
section of the GR-125 .tpp file. Table XXVIII illustrates the 
proper line of code required to incorporate this 74S181.v_out 
file into a GR-125 .tpp file. 

Table XXVIII INCLUDE STATEMENT FOR GR-125 .tpp 
FILE 



INCLUDE "74S181.V out" 



The vector_map translator program, developed in this 
chapter, has produced an extremely useful tool for hardware 
testing using the GR-125. Highly accurate test vector data, 
produced in the computer simulation environment, can now be 
directly placed into the GR-125 .tpp file without the need for 
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time consuming test vector edits or rewrites. Additionally, 
the chance for errors occurring within these test vectors also 
decreases significantly. As a result of these 
characteristics, this translator program has successfully 
solved the incompatibility problem between the digital design 
and hardware test environments. 
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Figure 31 "74 S 181 . v _ out " File 
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VI. CONCLUSIONS 



A. SUMMARY OF RESEARCH 

This thesis analyzed the digital testing process within 
two separate test environments. Chapter II focused on the 
hardware test environment by performing a detailed system 
description of the GENRAD (GR-125) Hardware Tester System. 
Therefore, chapter II accomplished the first major thesis 
objective. This description provided a detailed overview of 
the methodology required to successfully program and execute 
a GR-125 digital logic test. Additionally, the specific 
testing capabilities of the GR-125 were also evaluated. Next, 
chapter III described the digital test process inside the 
computer simulation (i.e. software) environment. The Mentor 
Graphics IDEA Series (v 7.0) QuickSim simulator provided the 
platform to analyze this digital design and test process 
within this environment. The emphasis of the discussion is 
centered on the test vector stimulation/response information 
format produced in the QuickSim simulator output file. This 
output file contains all of the basic information required by 
the test pattern portion of the GR-125 . tpp input file. 
However, the structure formats of the two environments are 
quite different and , therefore, incompatible. 
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Chapter IV provided a general methodology of using special 
UNIX tools, lex and yacc, to produce a successful computer 
language translation. This discussion gave the necessary 
background information required to solve the specific test 
vector format incompatibility problem between the QuickSim 
simulator output file and the GR-125 . tpp input file. Chapter 
V provided the actual solution to the second major thesis 
objective. This chapter presents the actual code used to 
translate the test vector stimulus/response information in the 
simulator output file into the format required by the GR-125 
.tpp input file. Therefore, a successful link between the 
software and hardware test environments has been accomplished. 

B. RECOMMENDATIONS FOR FURTHER RESEARCH 

This thesis discussed two extremely powerful programs in 
the standard UNIX toolkit (lex & yacc) . These programs 
provide an extremely useful mechanism for translating from one 
computer language to another. Although lex by itself provided 
an adequate capability to build the successful translator 
program, vector_map, developed in chapter V, a host of 
increasingly more difficult translator applications are 
possible with lex and yacc. 

The test vector translation program developed in this 
thesis successfully linked a computer simulator output with a 
hardware tester input. However, both the computer simulator 
(QuickSim) and the hardware tester (GR-125) are stand alone 
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systems. This situation requires a new translation program to 
be developed whenever a different simulator or ATE is used. 
Figure 32 illustrates this dilemma. Fortunately, a new IEEE 
standard is forcing more standardization. This standard is 
known as WAVES (Waveform And Vector Exchange Specification) . 
Basically, this standard will force all of the CAD simulation 
programs to produce a standard test vector format. Once this 
standard is fully implemented industry wide, only one 
simulator file format will be produced. As a result, the 
number of different translation programs required decreases 
drastically. Figure 33 illustrates this scenario. Now, all 
of the different hardware testers would use a common input 
test vector file format. Conforming with WAVES development of 
more generic test vector translation applications would be 
extremely advantageous. 



90 




91 




92 



LIST OF REFERENCES 



1. Fujiwara, Hideo, Logic Testing and Design for Testability, 
MIT Press, 1985. 

2. Bennetts, R. G. , Design of testable logic circuits, 
Addison-Wesley Publishers Limited, 1984. 

3. GR125 Manager's Guide, v. 2.3, GenRad, Inc., Concord, 
Massachusetts, 1990. 

4. GR125 Operator's Guide, v. 2.3, GenRad, Inc., Concord, 
Massachusetts, 1990. 

5. GR125 Programmer's Guide, v. 2.3, GenRad, Inc., Concord, 
Massachusetts, 1990. 

6. IDEA Series Schematic Capture User's Manual, v. 7.0, 
Mentor Graphics, Corp. , Beaverton, Oregon, 1989. 

7. QuickSim User's Manual, v. 7.0, Mentor Graphics, Corp., 
Beaverton, Oregon, 1989. 

8. 1984 LOGIC DATA BOOK, vol II, National Semiconductor 
Corp., Santa Clara, California, 1984. 

9. Mason, T. , and Brown, D., lex & yacc, O'Reilly and 
Associates, Inc., 1990. 



93 



INITIAL DISTRIBUTION LIST 



1. Defense Technical Information Center 2 

Cameron Station 
Alexandria, VA 22304-6145 

2. Library, Code 52 
Naval Postgraduate School 
Monterey, CA 93943-5002 

3 . Chairman Code EC 
Department of Electrical and 
Naval Postgraduate School 
Monterey, CA 93943-5000 

4. Professor Chin-Hwa Lee, Code 
Department of Electrical and 
Naval Postgraduate School 
Monterey, CA 93943-5000 

5. Professor Herschel Loomis, Code EC/Lm 1 

Department of Electrical and Computer Engineering 

Naval Postgraduate School 
Monterey, CA 93943-5000 

6. Naval Maritime Intelligence Center 1 

ATTN: Mr. Charles Bradley 

Building 75 

5803 Bayside Road 

Chesapeak Beach, MD 20730 

7. Naval Maritime Intelligence Center 1 

ATTN: Mrs. Janet Hooper 

Building 75 

5808 Bayside Road 

Chesapeak Beach, MD 20730 

8. LT James T. Loeblein 2 

410 Brownrigg Road 

Salisbury, NC 28144 

9. STEWS NE-A 1 

ATTN: John Sweeney 

Building 21225 

White Sands Missile Range 

White Sands, NM 88002 



2 



1 

Computer Engineering 



EC/Le 4 

Computer Engineering 



94 



DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 93943-5101 



GAYLORD S 



